                          SonED2 Art Importing

One key feature of SonED2 is the ability to import palettes and art from
image files. This allows the creation of level art in external programs.
The "Import from Image" option in the "File" menu contains selections to
import a palette, or any of the 3 tile sizes. Palette importing uses a
submenu, requesting a "Source ID" (where the colors start on the image's
palette), a "Destination ID" (where the colors should start in the
level's palette), and the number of color entries that should be copied.
A file selection box will appear for all import options, requesting the
location and name of the file that contains the data to import. Once the
file is selected, the import begins. For Tiles, Blocks, and Chunks, the
Status Window will announce the beginning and end of the import process,
as well as give the number of tiles that were previously stored in the
level, and the number of tiles that are stored after the import has
completed.

Two near-identical "from-scratch" example projects are included in the
"Example" folder (one for Sonic 1, and one for Sonic 2), along with the
source image. The data files are ready for inserting into a game, and
can be "played". To re-create them from the source image will require
a little work in all editor modes.



There are a few things to bear in mind when creating art externally.
Not following these rules will likely cause undesired results:

SonED2 can read 256-color PCX images of any size, if both the height and
width are even. It is preferred that the height and width be equal to
each other, however.

The Megadrive/Genesis uses a 64-color palette. The palette itself is divided
into 4 rows, each of which may only be used one at a time. This is because
each pixel in an 8x8 tile is stored as a 4-bit value, with a maximum value
of 15, which is an index into a palette row containing 16 colors (0-15),
with color 0 on each row being "transparant" (it is not drawn). The total
number of colors that can be generated is 512, which is less than the total
number that can be generated by a PC. This is because color components are
also stored as 4-bit values, and only even values are used (0, 2, 4, 6, 8,
10, 12, 14). Most art programs use an 8-bit value (0-256) for the Red, Green,
and Blue components of a color. Both have the same color range, but the
Genesis has significantly fewer shades in-between. It's 4-bit component
values correspond to multiples of 32 in the 8-bit component values. Anything
in-between would be rounded down to the nearest multiple of 32, meaning that
shades that are too similar will become the exact same color. For that
reason, a chart containing all 512 possible colors is included in the file
"MDColor.png". Using this chart to select colors will help eliminate bad
color value problems.

All game art is stored as 8x8 tiles, which are used by "mappings" to build 
larger images. In the case of level art, 8x8 tiles are mapped into 16x16
Blocks, which are then mapped into the 128x128 (Sonic 2 type) or 256x256
(Sonic 1 type) Chunks that make up the levels. The "mappings" contain the
palette row identifier, so a single tile may be reused several times with
different palette rows to show the same form with different colors. When
importing Blocks or Chunks, SonED2 will use the last pixel found within a
tile to determine which palette row to assign it within the Block. If colors
from different rows are used within the tile, they will become colors from
the row assigned to the tile (the same row entry as in the row they were
taken from). The very first color in the 64-color palette (entry 0) is safe
to use anywhere in any tile to represent transparancy, however.

Some art programs do strange things with the palette, such as not allowing
the user to specify which palette index to draw with if two palette entries
contain the exact same color (For example, if entry 4 and entry 17 contain
the exact same color, attempting to draw with entry 17 will actually draw
with entry 4, which can be seen by then changing the color in entry 4).
This can be avoided by changing one of the colors completely, or just 
slightly, so that there is no reason not to use the selected color, and
then changing it back when finished drawing. The same error can occur when
copying art from one image to another, and will occur if a palette is loaded
with a "Match Nearest Color" option. It is always a good idea to double-check
the image to make sure that the graphics program hasn't caused any palette
errors. Also, Color Reduction options will re-order the palette, so they
should only be used outside of any primary images, where the palette and art
intended for import are being built and stored.

It is best to use an art program that has a resizeable grid. Using the grid
will help ensure that all patterns are drawn in sizes that are multiples of
8, and that art that is moved or pasted is positioned properly. If the art
doesn't fit properly into the 8x8 grid, extra tiles will be created, reducing
the ammount of tiles that can be added later. Larger shapes that form Blocks
and Chunks also need to conform to a grid. Blocks should be positioned on a
16x16 grid, and Chunks should be positioned on a 128x128 (Sonic 2 type) or
256x256 (Sonic 1 type) grid. If the tiles are not positioned properly in the
image, they will not be imported properly, because the program cannot
otherwise know where the tile begins and ends.

SonED2 will attempt to "optimize" tile usage by automatically detecting
"mirrored" and/or "flipped" Tiles and Blocks. When an 8x8 or 16x16 shape is
encountered that can be displayed by changing the direction of a Tile/Block
that has already been stored is found, that tile is not stored, but instead,
the previously stored version is used to build the Block or Chunk that is
currently being imported, and the proper drawing direction flags are set.
When importing art that looks the same as art that is already stored, but
should contain different property settings, a new entry is NOT made for the
similar tile, because SonED2 cannot know that different properties are
required when it is reading an image file that does not contain them. The
tile must be copied within the editor, and the appropriate properties set.
Art that is already stored with properties set, when run through the import
function again, will not be stored in new entires with no properties set,
but will use the art that was already stored, with the properties that were
already set. If more than one entry that looks the same is already stored,
the art being read will be read as the first entry that is found, so if it
should actually correspond to a later entry, it must be corrected manually
within the editor. This could also cause unnecesary "copies" of larger tile
types, so it is reccommended that art that has already been imported not
be included with any new art intended for import.

Sonic 2 type games use 2 solidity paths and a path swapper object to
accomplish loops, however, Sonic 1 types use a single path, and a pre-
programmed Chunk test. Each level in a Sonic 1 type game can be given two
Chunk IDs to define as "loops". These chunks must have a visibly identical
copy immediately following themselves, with the original having solidity
filled in on the right half, and the copy having solidity filled in on the
left half. (For example, if Chunks 4 and 8 are "loop" chunks, they must
contain solidity on the right side, and must also have copies in Chunks 5
and 9, with solidity on the left side). The original and copy are swapped
back and forth in-game depending on which side the player is moving toward
them from.